Proposal to define common resources for OpenGIS Location Services

Spatial information is getting ever more prominent on the web. As envisioned by the Open Geospatial Consortium (OGC) a spatial strand has been woven into the web. However, the buildup of the geospatial web takes place with scarce utilization of OGC standards only. One reason might be of architectural nature. Many successful web services follow the paradigm of Representational State Transfer (REST). OGC has recently turned towards discussing RESTful OpenGIS Web Services. OpenGIS Location Services (OpenLS) have not been approached in that context. Thus, we propose to define common resources for OpenLS that can be exposed by RESTful Web Services. Spatial information is getting ever more prominent on the web. As envisioned by [McKee 1999] a spatial strand has been woven into the web. However, the buildup of the geospatial web currently takes place with only very scarce utilization of OGC standards. While institutional spatial data infrastructure initiatives driven mainly by geospatial experts heavily rely on OGC standards, most of the successful applications offering geospatial content on the web do not. Examples include Google Maps, MSN maps, Yahoo Maps and geo-tagged flickr photos or Wikipedia articles. Table 1 makes three points drawing upon the case of fulfilling a simple spatial task geocoding street addresses – through widely used Application Programmer Interfaces (APIs) on the web: First, multiple interfaces to the same functionality exist. This strongly feels like history repeating – a similar situation had been prevalent in the late 1990s ([OGC 2003], [Schmitz 2006]) and had led to OGC publishing the Web Map Service specification ([OGC 2001]). Second, none of those interfaces has been defined by OGC, even though two OGC standards would have been applicable: Gazetteer Service (WFS-G) ([Fitzke & Atkinson 2006]) and OpenGIS Location Services (OpenLS) Location Utility Service ([OGC 2005]). Third, all corporations offering these interfaces are members of OGC, but do, however, not adhere to its standards. Table 1 Multiple interfaces to geocoding functionality on the web Google http://maps.google.com/maps/geo?q=1600+Amphitheatre+Parkway,+Mountain+Vie w,+CA&output=xml&key=xyz Yahoo http://local.yahooapis.com/MapsService/V1/geocode?appid=xyz&location=701+First +Ave,Sunnyvale,CA MSN http://dev.virtualearth.net/services/v1/geocodeservice/geocodeservice.asmx/Geoco de?count=&query=%22new%20york%22&landmark=&addressLine=&locality=&postal Town=&adminDistrict=&district=&postalCode=&countryRegion=&mapBounds=%223 7.44869658591038,%20-115.06805419921876,%2036.41686211530031,%20117.12799072265626%22&currentLocation=&curLocAccuracy=&entityTypes=&rankB y=&culture=%22en-us%22&format=json&rid=xyz 1 Examples include the Infrastructure for Spatial Information in Europe (INSPIRE) or the Canadian Spatial Data Infrastructure GeoConnections 2 http://maps.google.com, http://maps.live.com, http://maps.yahoo.com, http://flickr.com 3 Having two open standards/interfaces for the same functionality defined by a single standards body speaks for itself in this context. A table conveying the very same message of multiple non-OGC interfaces defined by OGC members for the same functionality could easily have been compiled for the cases of finding points of interest near a certain location, reverse geocoding or calculating routes. They constitute the core bulding blocks of Location-Based Services (LBS). Thus, further rationale will focus on interfaces for this service category. Within the OpenLS initiative several services have been defined within this category ([OGC 2005]). Why is it that this readily available OGC standard has not been implemented in the real-life web applications introduced above? To analyze this in detail is future work. One reason seems to be the bulkiness and the high-level of complexity inherent to the OpenLS specification and OGC standards in general. It can partly be accounted for by the long-term process of consensus finding between a large group of geospatial experts. Still, the API for the Yahoo! Geocoder ([Yahoo 2008]) is explained in one simple webpage whereas the OpenLS specification ([OGC 2005]) is a document of 165 pages. Even though the latter offers way more options, it documents the different outcomes produced by the web (simple) and the geospatial (complex) communities respectively. Yet another reason seems to be of architectural nature. Many successful web services follow a Resource-Oriented architecture (ROA) ([Richardson & Ruby 2007]) as opposed to a Service-oriented architecture (SOA) that has guided currently available OGC interfaces ([Lieberman 2003]). It is worth to take a closer look at ROA and the underlying architectural style for distributed hypermedia systems called Representational State Transfer (REST). REST ‘has guided the design and development of the architecture of the modern Web’ ([Fielding 2000]). The core concepts of ROAs are obviously resources, their addresses (URIs), their representations and the links between them. Core properties include addressability of resources, statelessness, connectedness and use of a uniform interface (in the case of Web applications this is HTTP). Adhering to these principles is expected to lead to enhanced scalability, flexibility and simplicity, i.e. tapping the full potential of the Web. Web Services that do are referred to as RESTful. OGC and the wider geospatial community have recently turned towards discussing RESTful OpenGIS® Web Services. This has happened both internally ([Reed 2006], [Cappelaere et al. 2007], [Uslaender 2007], [Turner 2008]) and externally ([Mazzetti & Nativi 2008], [Lucchi et al. 2008]). Even though the promise of REST also appears to address OpenLS’ requirements, they have not yet been approached in that context. Especially the limited bandwidth available on mobile devices and the large number of potential concurrent users make the case for a scalable, flexible and simple interface (HTTP itself) to OpenLS. Thus, we propose to define common resources for OpenLS that can be exposed by RESTful Web Services. A shared understanding of resources is analogue to defining a common interface in a SOA. It allows for interoperability between different RESTful Web Services for LBS. The case of routing serves as a concluding example of how the OGC OpenLS Implementation Specification ([OGC 2005]) and the approach of defining common resources relate. Comparing SOA and RESTful Web Services [Tilkov 2008] states that ‘you can basically express anything you like with both approaches’. Thus, it is possible to express the functionality defined in the OpenLS interface specification as resources (Figure 1). 4 For an in-depth introduction to REST and ROA refer to [Richardson & Ruby 2007] (Ch. 4) HTTP Request GET /RESTfulOpenLS/routes/7.09+50.74/7.19+50.73/Fastest HTTP/1.1 ... HTTP Response HTTP/1.x 200 OK Content-Type: application/xml ... Figure 1: Expressing interfaces to routing functionality (a) service-oriented as defined in the OpenLS Specification and (b) as resources, i.e. resource-oriented (based on [Tilkov 2008], modified) Note that the service-oriented approach (a) only exposes one resource, its service URL, and defines novel operations. The resource-oriented approach (b) in contrast exposes a very high number of resources (one for each route) and relies on standard HTTP operations to retrieve and manipulate those. Working a more complete set of resources from the OpenLS Specification remains future work. A first step is the specification of an HTTP GET syntax for OpenLS partly building on the APIs in Table 1 that could be presented in a full paper. One of the challenges is expressing given semantics with a simpler syntax. Figure 2 presents a HTTP request to a first prototypical implementation of a RESTful Web Service addressing a route as a resource. One possible representation of a route can be XML for Location Services as specified in the OpenLS Implementation Specification ([OGC 2005]). Others representations may be defined. Figure 2: Route request against a prototypical RESTful OpenLS Route Service Our implementation operates on OpenStreetMap data and has been preliminarily realized as a simple wrapper around existing OGC OpenLS-compliant software ([Neis & Zipf 2008]). A similar approach has been taken by [Mazzetti & Nativi 2008]. It can be used to evaluate the feasibility of the presented approach. 5 Refer to http://www.openstreetmap.org a) b) Interface Resource + GET + POST + PUT + DELETE /routes/{here}/{there} + GET: request route + POST: unused + PUT: unused + DELETE: unused RouteService